Sujet de these: ASPECTS THEORIQUES ET PRATIQUES DE L'INFERENCE DE TYPE ET D'EFFETS

ion To translate an abstraction the compiler rst compiles the body of the source FX abstraction Then if the lambda abstraction can be parallelized according to the predicate PF de ned below an f structure initialization is generated which pairs up the sequential version of the function generated by SC with its parallel version generated by PC presented in the next section SC lambda x te x ' let d 'STD x c 'SC te x c ' lambda x d c in if PF then let fi i i n ' ffi i te n x j i ' i i i i i g d 'PTD x c 'PC te x x c ' lambda x d c in if and f struct p f f struct p fn make f struct c c c else c Compilation of Abstraction If the function is not parallelizable then the compiler returns the sequential version c of the function The algorithms STD and PTD respectively generate the sequential and parallel type declarations The compiler uses the following static criterion PF based on the type of the function to determine if it can be parallelized De nition Parallelizability Criterion A lambda expression of type is parallelizable satis es the criterion PF if and only if its latent e ect is or a union of e ect variables and if the types and are scalar data types type variables or function types that satisfy the criteria PF ' PA PA PE where PA case of bool j int j real j true PF otherwise false PE case of j true PE PE otherwise false This criterion has both compile time and runtime aspects Its compile time aspect can be informally justi ed in the following way First the lambda expression must have no side e ects no write e ects write must occur in since they could generate non determinism at run time Also no initialization init or read e ects read may appear as they would indicate that the function allocates or manipulates non scalar values which are unimplementable on the Connection Machine Second the types and must be scalar variables or function types Runtime checks are only required in the presence of e ect variables in to distinguish whether these e ect variables actually are or not in each given instance These e ect variables are introduced by the latent e ects of higher order functions other lambda bound function identi ers However we known that every pure rst order function is compiled as an f structure Thus we use the predicate f struct p to decide at runtime whether the free function identi ers of a lambda abstraction actually correspond to other f structures When this condition is met an f structure is returned CHAPTER COMPILING FX ON THE CM Example For instance the code generated for lambda g lambda x g x is as below The iden ti er id is fresh and the Lisp function funcall applies a function value operating on pvars to its arguments and is used inside the parallel code lambda g let id lambda x funcall if f struct p g f seq g g x if not f struct p g id make f struct id lambda x funcall f par g x Application As already illustrated by the previous example the general compilation scheme for an application is rst to translate both subexpressions and then to generate the Lisp code that checks at runtime whether the called function is a f structure SC te te x ' let f fresh c'SC te x c 'SC te x in let f c funcall if f struct p f f seq f f c Compilation of Application Simpli cations More e cient compilation mechanisms for vector operations are given in the subsection However simple syntactic rewriting rules can be used to already improve the code generated by the previous technique They are f seq make f struct c c c f par make f struct c c c funcall * c c c c funcall * c c c c For instance the combination of boxing unboxing of functions done via make f struct f seq and f par can most of the time be simpli ed This is also the case with the combination of Lisp special forms and funcall f struct p make f struct c c t f struct p * lambda x c nil if t c c c if nil c c c In the same manner we can simplify many runtime tests that are performed using f struct p and reduce the related if expressions let id make f struct c c c c make f struct c c id let id * lambda x c c c * lambda x c id Let bindings introduced by our tiny compiler can also be safely inlined Then handling the substituted expressions reduces itself to using the previous simpli cation rules PARALLEL CODE GENERATION Parallel Code Generation We describe the Lisp parallel code generation scheme implemented by the algorithm PC te x ' c which given a typed FX expression te and a sequence of parallel value identi ers x generates the parallel Lisp code for it to run on the CM processors Parallel value identi ers in x are either prede ned arithmetic operations such as or which are implemented on the CM or user value identi ers bound by lambda abstractions Identi er The compiler translates a lambda bound identi er x appearing in the sequence x by x Free identi ers correspond to values that are imported in the parallel code PC x x ' if x x then x else case of bool j int j real let t ' PT in coerce x quote t f par x distribute x otherwise front end x Compilation of Identi ers Scalar identi ers x as well as constants n are distributed and coerced to a pvar of the corresponding type The function PT associates a type with its corresponding Lisp pvar type Functions identi ers f are translated to f par f Identi ers of variable type use the type dispatching expression distribute x of the FX runtime library to precisely distinguish at run time between the previous cases Other mutable data structure identi ers are guaranteed by the static semantics to never be used Abstraction In the compilation of lambda abstractions since Lisp doesn t create real closures the free pvar identi ers of the compiled lambda expression must be heap allocated because the lambda abstraction may escape from the stack frame at which those pvar identi ers are allocated The function ST associates a type with its corresponding Common Lisp data typeion In the compilation of lambda abstractions since Lisp doesn t create real closures the free pvar identi ers of the compiled lambda expression must be heap allocated because the lambda abstraction may escape from the stack frame at which those pvar identi ers are allocated The function ST associates a type with its corresponding Common Lisp data type PC lambda x te x ' let xi i i n ' fxi i te x n x j i is not of the form i i i g ti i n ' ST i di i n ' PTD x i d'PTD x c'PC te x x in let x t heap allocate x xn tn heap allocate xn declare d dn lambda x d c Compilation of Abstraction CHAPTER COMPILING FX ON THE CM Application The parallel code generated for the application is PC te te x 'let c'PC te x c 'PC te x in funcall c c Compilation of Application If constructs Parallel if expressions are translated into Lisp if expressions The compilation of if dif fers from standard applications for two reasons First the semantics of the Lisp expression if e e e is to execute both e and e and return the value of e where e is true and e otherwise To ensure ter mination we add code to check that at least one processor is active before executing the if form itself Second if expressions can only return pvars even though FX if expressions may return functions Thus calls to these functions must be interned within the branches of the if construct Example Before being compiled the expression if b x is rst transformed into lambda y if b y y x where the function expression if b is abstracted over a fresh y This expression gets compiled into the following Lisp code where or performs a machine wide reduction If no processors are active nil is returned by or lambda y if or t if b y y